Skip to content

chore: Prevent conflict between clang-format and MSVC by wrapping inline assembly blocks in curly braces#2811

Merged
xezon merged 1 commit into
TheSuperHackers:mainfrom
githubawn:fix/assembly-syntax
Jun 19, 2026
Merged

chore: Prevent conflict between clang-format and MSVC by wrapping inline assembly blocks in curly braces#2811
xezon merged 1 commit into
TheSuperHackers:mainfrom
githubawn:fix/assembly-syntax

Conversation

@githubawn

@githubawn githubawn commented Jun 19, 2026

Copy link
Copy Markdown

When running clang-format on the codebase, it collapses consecutive unbraced inline __asm statements onto a single line.
If a standard C++ statement (such as return) immediately follows, it also gets merged onto that same line.

This PR prepares the codebase for the upcoming formatting baseline pass by isolating the inline assembly instructions into standard braced blocks (__asm { ... }).

When running the updated clang-format recursively across the entire repository (Core/, Generals/, GeneralsMD/, and scripts/), these are the only two files that required syntax adjustments to compile successfully on both modern VS2022 and legacy VC6 toolchains. This avoids adding //clang-format off.

@greptile-apps

greptile-apps Bot commented Jun 19, 2026

Copy link
Copy Markdown

Greptile Summary

This PR wraps consecutive unbraced __asm statements into standard __asm { ... } blocks across two header files to prevent clang-format from collapsing them onto a single line (which would break MSVC parsing). The change is purely syntactic — no assembly instructions are added, removed, or reordered.

  • wwmath.h: fld/fistp pair grouped into one __asm { } block; the FPU stack discipline and return value are unchanged.
  • internal.h: Both spin-lock retry loops use braced blocks; the backward jc jumps to a C++ label (The_Bit_Was_Previously_Set_So_Try_Again) defined between the two blocks, which MSVC's inline assembler resolves correctly — the wait-and-retry control flow is preserved exactly.

Confidence Score: 5/5

Safe to merge — the changes are purely syntactic, introducing no behavioural differences.

Both files receive a mechanical wrapping of existing consecutive __asm statements into braced blocks. No instructions are added or removed, FPU stack discipline in wwmath.h is unchanged, and the spin-lock retry loop in internal.h preserves its control flow including the backward jc jump to a C++ label, which MSVC's inline assembler handles correctly. No custom rules are violated.

No files require special attention.

Important Files Changed
Filename Overview
Core/Libraries/Source/WWVegas/WWMath/wwmath.h Two consecutive unbraced __asm statements (fld/fistp) wrapped into a single __asm { } block; semantically equivalent and safe.
Core/Libraries/Source/profile/internal.h Two groups of unbraced __asm statements wrapped into braced blocks; backward jc jumps to C++ labels still resolve correctly within MSVC's inline assembler and the spin-lock logic is preserved.

Flowchart

 
%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[ThreadSafeSetFlag called] --> B["__asm block 1: mov / ts_lock / bts / jc"]
    B -- "carry clear (bit was 0 → now 1)" --> C[return]
    B -- "carry set (bit was already 1)" --> D[The_Bit_Was_Previously_Set_So_Try_Again label]
    D --> E{testEvent ?}
    E -- yes --> F[WaitForSingleObject testEvent 1ms]
    E -- no --> G["__asm block 2: mov / ts_lock / bts / jc"]
    F --> G
    G -- "carry clear (bit acquired)" --> H[fall-through / close brace]
    G -- "carry set (still locked)" --> D
Loading 
%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[ThreadSafeSetFlag called] --> B["__asm block 1: mov / ts_lock / bts / jc"]
    B -- "carry clear (bit was 0 → now 1)" --> C[return]
    B -- "carry set (bit was already 1)" --> D[The_Bit_Was_Previously_Set_So_Try_Again label]
    D --> E{testEvent ?}
    E -- yes --> F[WaitForSingleObject testEvent 1ms]
    E -- no --> G["__asm block 2: mov / ts_lock / bts / jc"]
    F --> G
    G -- "carry clear (bit acquired)" --> H[fall-through / close brace]
    G -- "carry set (still locked)" --> D
Loading

Reviews (1): Last reviewed commit: "fix(build): wrap inline assembly blocks ..." | Re-trigger Greptile

@xezon xezon added Minor Severity: Minor < Major < Critical < Blocker Refactor Edits the code with insignificant behavior changes, is never user facing labels Jun 19, 2026
@xezon

xezon commented Jun 19, 2026

Copy link
Copy Markdown

Is the change title accurate? Why is it labelled as accomodating the MSVC parser? Isn't it accomodation clang format instead?

@githubawn

githubawn commented Jun 19, 2026

Copy link
Copy Markdown
Author

Clang doesn't throw warnings or errors, it is perfectly happy working with these files. It is the MSVC compiler parser that fails to compile the resulting formatted code.

Both titles are accurate depending on perspective and what someone feels it should communicate. Feel free to change the title if you prefer!

@xezon xezon changed the title chore: Wrap inline assembly blocks in curly braces for MSVC parser compatibility chore: Prevent conflict between clang-format and MSVC by wrapping inline assembly blocks in curly braces Jun 19, 2026
@xezon

xezon commented Jun 19, 2026

Copy link
Copy Markdown

Tweaked

@xezon xezon merged commit e577fad into TheSuperHackers:main Jun 19, 2026
17 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@xezon xezon xezon approved these changes

Assignees

No one assigned

Labels

Minor Severity: Minor < Major < Critical < Blocker Refactor Edits the code with insignificant behavior changes, is never user facing

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@githubawn @xezon